Закони Мерфі в програмуванні

Володя Штеньович RSS стрічка новинRSS стрічка новин

Закони Мерфі в програмуванні

 
Вирішив скласти список законів Мерфі спроектувавши їх на IT галузь. Ось що получилося: 
 
Закон Мерфі
Якщо неприємність може статися - вона станеться

Висновки:

  • Будь-яка задача вимагає більше часу, ніж ви думаєте
  • Із усіх можливих проблем виникне та через яку треба буде переписати найбільше коду
  • Якщо чотири можливі причини помилки усунуті заздалегідь, то завжди знайдеться п'ята
  • Залишені без втручання програмісти мають тенденцію все більше ускладнювати систему
  • Як тільки ви візьметеся за термінову задачу, прибіжить менеджер з ще більш критичною задачею
  • Будь-яке вирішення проблеми створює нові проблеми

 

Наслідки з закону Мерфі
  • Код який ви зберігаєте достатньо довго можна викинути
  • Як тільки ви його викинете він вам знадобиться
  • На іншій мові програмування/бібліотеці ця задача вирішується швидше
  • Система обробки помилок першою завалить вашу програму
  • Критичні помилки виникають як правило в ніч на суботу
  • Всі найкращі ідеї приходять в голову за секунду після коміту
  • Якщо ви одночасно натиснули дві клавіші на клавіатурі спрацює та яку ви натиснули випадково
  • Яка б помилка не сталася завжди знайдеться той хто знав що так воно і буде

 

Перший закон Чізхолма

Вимоги до проекту міняються
Висновок: Вимоги які не можуть помінятися поміняються також


Другий закон Чізхолма

Якщо проект розробляється відповідно до графіку роботи, щось обов'язково трапиться в найближчому майбутньому
Висновок: Коли ви не встигаєте по термінах гірше нікуди, скоро все піде ще гірше
Висновок 2: Якщо вам здається що ви наздоганяєте графік робіт значить ви чогось не помітили.


Третій закон Чізхолма

Будь-які пропозиції люди сприймають інакше, ніж той, хто їх вносить.
Висновок: Навіть якщо ваше пояснення настільки ясне, що виключає будь-яке хибне тлумачення, завжди знайдеться людина, що зрозуміє вас неправильно.


Перший закон Скотта

Неважливо, що код некрасивий і крива архітектура. Можливо, це добре виглядає...


Перший закон Фінейгла

Якщо багів у системі не знайдено то щось тут не так


Другий закон Фінейгла

В будь-якому наборі вихідних даних найнадійніша величина, що не вимагає ніякої перевірки, є помилковою


Третій закон Фінейгла

Якщо проект провалюється, то будь-яка спроба врятувати його тільки погіршить справу

Я в твіттері
Brainbench test C# 4.0
Volodymyr Shtenovych